As used herein, the term “device” can refer to the terms “mobile station” (MS), “user agent” (UA), or “user equipment” (UE) which can include electronic devices such as fixed and mobile telephones, personal digital assistants, handheld or laptop computers, smart phones, printers, fax machines, televisions, set-top boxes, and other video display devices, home audio equipment and other home entertainment systems, home monitoring and control systems (e.g., home monitoring, alarm systems and climate control systems), enhanced home appliances such as computerized refrigerators and similar devices that have network communications capabilities. In some configurations, UE may refer to a mobile, wireless device.
UE may also refer to devices that have similar capabilities but that are not readily transportable, such as desktop computers, set-top boxes, TVs, IPTVs or network nodes.
The term device may also refer to a Session Initiation Protocol (SIP) User Agent (UA) that can be fixed or mobile. When a UA is a network node, the network node may act on behalf of another function, such as a UA or a fixed line device, and simulate or emulate the UA or fixed line device. For example, for some UAs, the Internet Protocol (IP) Multimedia Subsystem (IMS) SIP client that would typically reside on the device actually resides in the network and relays SIP message information to the device using optimized protocols. In other words, some functions that were traditionally carried out by a UA can be distributed in the form of a remote UA, where the remote UA represents the UA in the network.
The term “UE” can also refer to any hardware or software component that can terminate a communication session that could include, but is not limited to, a SIP session. Also, the terms “user agent,” “UA,” “user equipment, “UE,” and “node” might be used synonymously herein. Those skilled in the art will appreciate that these terms can be used interchangeably within the application.
A UE may operate in a wireless communication network that provides high-speed data communications using various network configurations and/or Radio Access Technologies (RATs). For example, the UE may operate in accordance with Global System for Mobile Communications (GSM) and General Packet Radio Service (GPRS) technologies. Today, such a UE may further operate in accordance with Enhanced Data rates for GSM Evolution (EDGE), or Enhanced GPRS (EGPRS) or Enhanced GPRS Phase 2 (EGPRS2). Other wireless networks that UEs may operate include but are not limited to CDMA, UMTS, E-UTRAN, WiMax, and WLAN (e.g. IEEE 802.11). UEs may also operate in fixed network environments such as xDSL, DOCSIS cable networks, Ethernet or optical networks. Some UEs may be capable of multimode operation where they can operate on more than one access network technology either on a single access network technology at a time or in some devices using multiple access network technologies simultaneously.
In wireless telecommunications systems, transmission equipment in a base station transmits signals throughout a geographical region known as a cell. As technology has evolved, more advanced equipment has been introduced that can provide services that were not possible previously. This advanced equipment might include, for example, an evolved universal terrestrial radio access network (E-UTRAN) node B (eNB) rather than a base station or other systems and devices that are more highly evolved than the equivalent equipment in a traditional wireless telecommunications system. Such advanced or next generation equipment may be referred to herein as long-term evolution (LTE) equipment, and a packet-based network that uses such equipment can be referred to as an evolved packet system (EPS). As used herein, the term “access device” may refer to any component, such as a traditional base station, eNB, or other LTE access device, that can provide a UE with access to other components in a telecommunications system.
In Third Generation Partnership Project (3GPP) systems, voice services can be provided by a mobile operator via a series of means. Over GPRS/EDGE Radio Access Network (GERAN) and Universal Terrestrial Radio Access Network (UTRAN), for example, Circuit Switched (CS) infrastructure may be used to provide voice services. Alternatively, over GERAN and UTRAN, the IMS- or IP Core Network (CN) Multimedia Subsystem can be used. In that case, voice-over-IP or voice communication using IMS may be termed IMS voice over packet switched (PS). Furthermore, a hybrid solution where CS is used to provide the voice bearer and IMS is used to control the voice bearer can also be supported, this is know as IMS Centralised Services (ICS) and is defined in 3GPP TS 23.292 and 3GPP TS 24.292. Over (E-UTRAN), the IMS may be used. In some cases, voice services over LTE network (i.e. with the UE actively connected and exchanging data over an LTE network) may be provided using IMS.
Various Voice Service Indicators (VSIs) have been defined to indicate under what circumstances a particular network, network area or network cell may provide voice services. The indicators include the following values: “IMS Voice over PS session supported” (i.e., VoIMS Indicator), “Voice Centric” or “Data Centric”, and “CS Voice only”, “IMS PS voice only”, “CS voice preferred, IMS voice secondary” or “IMS voice preferred, CS voice secondary”. The VoIMS indicators may be provided by the network to the UE at each NAS registration (e.g. EPS attach) and NAS registration update while the “Voice Centric” or “Data Centric” indicators are within the UE. In some cases, an absence of the “IMS Voice over PS session supported” indicator may suggest the network (e.g., an eNodeB) is not optimized for voice. In some cases, however, voice may still be supported even though it may not be preferred. The preference could be specified as an operator preference, a user preference, a subscriber preference or combinations thereof. The user, the subscriber (e.g. enterprise) and/or the operator can manage the preferences. The preference can apply per access network, e.g. a different preference may exist for E-UTRAN when compared to another access network such as WIMAX or IEEE 802.11 based access networks. Such a preference may not be associated with each and every access network a UE supports. An operator's network elements may be aware of the preference such that voice calls are not delivered or terminated using a less preferred access network if preferred alternatives exist.
In the present disclosure, the VSIs may be categorized in several manners, including: Network provided VoIMS indicators (or IMS voice over PS (IMSVoPS) indicators), which are comparable to the above referenced “IMS Voice over PS sessions supported” indication, and a UE's usage settings may equate to the above-referenced “Voice Centric” or “Data Centric” VSIs. Voice Centric UEs may be able to use voice services, and therefore may attempt to obtain voice services independently of how the services may be provisioned. In contrast, Data Centric UEs may prefer to have the best possible PS (Packet Switched) services even when voice services are not available. For example, Data Centric UEs may prefer to stay in E-UTRAN, even when voice services are not available on the E-UTRAN. Voice services may be provided for Data Centric UEs depending on the operator's service scenario. Finally, a UE's voice settings may equate to the above-referenced “CS Voice Only”, “IMS PS Voice Only”, “CS Voice Preferred, IMS Voice Secondary”, or “IMS Voice Preferred, CS Voice Secondary” VSIs. The following table (Table 1) summarizes these grouping and naming conventions.
TABLE 1Generic Name ofIndicator used inOwnership ofthis ApplicationName of Indicators in the SpecificationsindicatorsVoIMS indicator“IMS Voice over PS session notSet by Network.orsupported” orProvided by NetworkIMS voice over“IMS Voice over PS session supported”to UE at each NASPS indicatorregistration (e.g. EPSattach) and NASregistration updateUE usage“Voice centric” orCould be provisionedsettings“Data centric”by Operator or couldbe changed by the UEfor example as a resultof user input.UE voice settings“CS Voice only” orCould be provisioned“IMS PS voice only” orby Operator or couldCS voice preferred, IMS voicebe changed by the UEsecondary” orfor example as a result“IMS voice preferred, CS voice secondary”of user input.
As wireless communication networks continue to evolve, in some network implementations there may be islands of coverage of LTE-type networks residing within a more complete radio coverage provided by GERAN and/or UTRAN. As such, various mechanisms for delivering voice services to a UE connected to an LTE network have been defined. For example, a CS fallback procedure allows a UE connected to a network using a first RAT, where the RAT provides only PS (Packet Switched) domain services, to also register simultaneously to another network that provides CS domain services. CS fallback may be used, for example, to trigger the UE to move to a cell of a network providing CS domain services and initiate voice calls, when, at the time of initiating the voice call, the UE was associated to a cell of a network that only provides PS domain services (i.e. no CS domain services). The UE initiating the voice call may be either idle or active on the cell of the network that only provides PS domain services. The term “register” has been used in this document for two purposes: (1) describing the act of registering a SIP UA with a SIP REGISTRAR, and (2) DESCRIBING THE ACT OF registering with lower layer(s). In SIP, when a UA is registered, typically a SIP REGISTER request was transmitted by the UA and a SIP 200 (OK) response is received by the UA. Alternatively, the UA may be registered via other means. In this document, we use the term “IMS register” if the UA is registered with a REGISTRAR function on a node or functional element that is an IMS node of functional element. Typically, the S-CSCF performs the role of REGISTRAR in IMS. At lower layers, e.g. at the NAS or Access Stratum layers, the UE registers with the network to obtain connectivity either by performing an Attach procedure to the GPRS network over UTRAN or GERAN, or an Attach with the EPC over LTE or E-UTRAN. Registration at NAS layer may also refer to the concept of Routing Area Update, Tracking Area Update (TAU), NAS Combined Attach and Combined TAU. It should be clear from the context which “register” applies, throughout this document.
Specifically, for the case where the operator is incrementally deploying LTE and has not deployed IMS, the CS fallback procedures allow a UE to: simultaneously attach to the PS core network (i.e. the 3GPP Evolved Packet Core (EPC)) and to the CS domain (i.e. the Mobile Switching Center (MSC)) by performing a combined Attach procedure at initial attach or a combined Tracking Area Update procedure in case of mobility; exchange data services over LTE while being capable of receiving incoming CS call notifications to trigger the UE to perform a handover to another RAT (GERAN or UTRAN) and continue the establishment of the CS call using the CS domain; and exchange data services over LTE while being capable of establishing outgoing CS calls by handing over to another RAT (GERAN or UTRAN) and performing the establishment of the CS call using the CS domain.
A UE may be configured to support voice service in a number of ways over an LTE. For example, the UE may support voice over IP solutions not provided by the network operator (e.g. Skype), CS fallback, IMS or Voice over LTE via Generic Access (VoLGA). As described above, there are a number of message tags for defining whether IMS is available over a particular LTE (e.g., VoIMS, SRVCC). Furthermore, a UE may be configured to select an initial or preferred voice solution based upon a pre-determined logic tree. If the initial voice solution is not available, the UE may be configured to react based upon pre-determined logic rules.
When a mobile terminated session is presented to the IMS network (e.g. including a node like the IMS Application Server (AS)), the node determines how to choose a target domain for the call delivery (i.e., CS Domain or PS Domain). A target domain may be defined as a result of IMS registration over the LTE network or the E-UTRAN, or by being configured with a CS target address, where the CS target address is provided e.g. as a result of a combined attachment procedure. In some cases, when registering, if the UE discovers that VoIMS or Single Radio Voice Call Continuity (SRVCC) are not supported, the UE may not include an indication such as an “audio” feature tag or an IMS Communication Service Identifier (ICSI) (e.g. the Multimedia Telephony (MMTel)) in its registration information. However, because an “audio” feature tag may describe more services than only bidirectional full duplex voice, the absence of the “audio” feature tag may deny the UE access to many more services such as streaming music or radio over IP. Similarly, absence of an MMTel ICSI may deny particular services (e.g. file transfer) in accordance with MMTel specifications. Note that the acronym “AS” has been used in this document for two purposes: (1) identifying node or functional element “application server”, and (2) identifying “access stratum”. In SIP, when a UA requests a service, and another UA renders or provides the service, typically a SIP request message was transmitted by the UA to another UA. The other UA can be hosted on a node or functional element called “application server” in IMS. Typically, an I-CSCF or S-CSCF or E-CSCF routes a request to an application server. It should be clear from the context which “AS” acronym applies, throughout this document.
Generally, the IMS AS, after receipt of an IMS registration message, is not aware of whether the LTE access can support voice services. The IMS AS may then rely upon other information rather than the information contained in IMS registration message to determine how the session (including voice) should be routed or whether the UE should be given the option to determine how the session (including voice) should be routed. If the UE is given the option to determine how the session (including voice) should be routed, the UE determines how to respond upon receipt of a SIP INVITE with an offer for a mobile terminated call or one including voice. In the present disclosure, the IMS AS may be a Service Centralization and Continuity Application Server (SCC AS).
In view of changing standards, a UE may receive an indication that certain services are supported while connected to a RAT, e.g. an “IMS Voice over PS session supported” indication when connected to GPRS or LTE/EPC/E-UTRAN received upon performing Attach, Tracking area update, Routing Area Update or combined attach procedures. Due to performing a registration area update procedure, the “indication that certain services are supported” may change. As a result, if the UE receives services (as provisioned for the subscriber) from the IMS domain and has also registered, the UE may not be capable of obtaining some services offered by the IMS domain and authorized as part of the subscription on the access network depending on the present value of the “indication that certain services are supported”.
In some instances, problems relate to the delivery of services (e.g. a Mobile-Terminated voice call) to the UE depending on how services are provided to the UE, the value of the VoIMS Indicator, and the UE usage and voice settings. In particular, the problem may apply to scenarios where the UE can receive the services over a variety of RATs and voice solutions, and the RAT the UE prefers (e.g. the RAT determined to be preferable based on policies in the UE) does not support the service/feature required. Note that, in some cases, the RAT that the UE prefers is never defined.
For example, a UE may be registered with IMS, over LTE or using E-UTRAN in an area where VoIMS is not available as indicated by the VoIMS Indicator. Similarly, SRVCC may be unavailable; the SRVCC flag may not be set. If the VoIMS Indicator is not supported, no indication may be made available by the network or made available by lower layers in the UE. In that case, the UE may be unable to determine before performing IMS registration, or after IMS registration but before establishing an IMS voice (VoIMS) session, whether VoIMS is supported. The absence of the VoIMS indicators may imply by default that VoIMS either is or isn't supported.
As such, upon IMS registration, the UE may be unable to indicate to the IMS infrastructure whether the UE intends to use IMS for voice services. Furthermore, even assuming that the UE is configured to indicate to the IMS (e.g. upon registration) whether it intends to use IMS for “voice” services or just for “non-voice” services (e.g. when the UE desires “voice” and “non-voice” services but the VoIMS indicator was not present or indicated that VoIMS is not available), it may be unclear how Mobile-Terminated calls incoming to the IMS are delivered when the UE is camping on a PS RAT (e.g. LTE), or how calls can be routed to the UE over the CS domain. Accordingly, it may be unclear as to whether calls are routed to the UE using IMS over the PS RAT in the PS domain or whether calls are routed through the CS domain.
In a UE where the UE IMS or SIP stack has no access to the indications that were provided by the NAS regarding the value of the VoIMS indicator, the UE does not know whether the UE can receive or initiate IMS voice in certain areas. In some cases, the IMS or SIP stack in the UE may register first with IMS with the intention of using IMS for VoIMS sessions and later the NAS may realize through the VoIMS Indicator that VoIMS is not available. In that case, it may be difficult for the IMS or SIP stack in the UE to indicate to the network that calls should not be delivered over IMS, and the core network infrastructure cannot distinguish between these two cases. As such, when the AS/NAS layer of a UE registered to the IMS knows through the VoIMS indicator that IMS voice calls are not possible and there is an incoming call being directed to the UE over IMS, the IMS stack in the UE might still accept the incoming voice call e.g. because the IMS stack is not tightly integrated with the AS/NAS stack and the IMS stack does not have the VoIMS indication. This problem may also arise when the UE performs an incorrect operation in accepting the incoming call over IMS.
A further problem may arise in cases where a UE has more than one voice solution running (i.e. different applications: examples are VoLGA and IMS). One voice solution may be provided by the operator (OpVoice), and one or more solutions may be provided by other parties via IMS (e.g. enterprise voice provided by enterprise), or AppVoice and AppIMS. In that case, to access OpVoice services, the UE may implement current solutions (e.g. those defined in 3GPP) for selection of IMS, CS fallback, and any other possible solutions (e.g. VoLGA). To access AppVoice, the UE may connect to the AppIMS infrastructure. The decision of whether to connect to AppIMS may not be based on the same rules/mechanisms used for OpVoice, because, if the UE decides to connect to AppIMS only when the VoIMS indicator from the transport layer is available and the network indicates that IMS is available, then the UE may not attempt IMS registration for other services. If the UE instead registers for AppVoice with AppIMS, routing problems on incoming AppVoice calls may need to be solved because the UE may not be in an area where the VoIMS indicator states that IMS voice calls are not supported (e.g. due to QoS).
In other words, problems may arise when the UE 1) is connected to the network and selects the voice solution for OpVoice as currently specified in 3GPP (i.e. based on the VoIMS indicator, the success or failure of CS fallback combined registration/TAU, etc.), or 2) the UE is connected to AppIMS for AppVoice based e.g. on policies provided to the UE by the AppVoice provider. Even if the VoIMS indicator is available and indicates no IMS voice is possible, or the VoIMS is not available, the UE may register for AppVoice with AppIMS if the policies indicate that the UE shall do so. The problem may also arise when the UE 3) is in an area where the VoIMS indicator states that IMS voice is not supported, or 4) when the AppVoice solution is not integrated with other voice solutions in the UE (e.g. VoLGA, CS fallback, etc.) and therefore the UE cannot “fallback” to other solutions to provide AppVoice to the UE when IMS voice is not available. The AppVoice stack may be separate from the OpVoice stack in the UE.